For many companies, one of the most important business processes is the movement of perishable goods through the temperature-controlled portions of a supply chain. In many instances, proper operation of the so-called “cold chain” is critical to maintaining the quality of such goods.
Each year, companies spend millions of dollars on refrigerated staging and processing areas, storage, transport, display and/or specialized packaging. Many of them, however, do not know how well the entire, and very expensive, process works.
Traditional temperature monitoring programs are generally used to make accept/reject decisions or for dispute resolution. They are typically not designed to help a company identify and address problems or inefficiencies in its cold chain. Measuring the effectiveness of the cold chain can enable a company to identify and address such problems or inefficiencies, which might otherwise go undetected.
FIG. 1 is a block diagram of a prior art system 100 for cold chain analysis that has been employed in the past by the assignee of the present invention. As shown, the system 100 included a temperature sensor 102 which was associated with a quantity of product 104 as the product 104 was transported from a shipping location 106 to a receiving location 108. At the shipping location 106, a hand-held data entry device 110 would be used to manually enter data concerning the product 104 and the temperature sensor 102 associated with it. The data entered in the device 110 was then transmitted to a database 112 at a remote location 114. In some circumstances, the shipper would instead communicate information associating the sensor 102 with the product 104 to the remote location 114 in another manner, such as (1) by sending a packing list for the product, including the sensor identification (ID), by facsimile to the remote location 114, (2) by sending a database containing such information to the remote location 114 on a regular basis, e.g., monthly, or (3) by simply writing product identification information on the sensor 102.
Before the product 104 left the shipping location 106, a person manually depressed a “start” button on the sensor 102 so as to cause the sensor 102 to begin logging temperature information at regular intervals, e.g., every five minutes.
After the sensor 102 reached the receiving location 108, someone would either download the information from the sensor 102 via a downloading device 116 and transmit the downloaded data to the database 112 at the remote location 114, or would ship the sensor 102 to the remote location 114, where data would then be downloaded from it and uploaded to the database 112. At this time, the data collected by the sensor 102 would be associated with the shipment information gathered by the handheld device 110 so as to create a complete record containing information about the shipment, its contents, and the data recorded by all associated sensors.
Some sensors 102 were equipped with “stop” buttons, which may or may not have been activated when the sensors 102 and associated products 104 reached the receiving location 108.
FIG. 2 shows an example of how the data would typically appear when it was first uploaded to the database 112. Since all of the uploaded data was not necessarily accumulated during a period of interest, e.g., the sensor 102 may have been started before it was associated with a product 104 or before the product 104 had entered the supply chain being monitored, or may have been stopped after it was separated from the product 104 or after the product 104 had exited the supply chain being monitored, the data had to be “conditioned” so as to reflect only the period of interest. This conditioning was done manually based on the information that was made available to, and the past experience of, the person performing the conditioning, and therefore required that person to make an educated guess concerning the portion of the data that should properly be used for further analysis.
In the example shown in FIG. 2, it appears likely that the sensor 102 was started several hours before it was associated with a product 104 in the cold chain, and was stopped or had data extracted from it approximately one half hour after it was separated from the product 104. Thus, if this raw (unconditioned) data had been used to perform any type of analysis, the results of that analysis would have been inaccurate and unreliable.
FIG. 3 illustrates an example of how beginning and ending locations for the raw data from a sensor 102 were marked during the conditioning step, with the line 302 identifying the beginning point and the line 304 identifying the ending point 304. To determine how the data should be conditioned, a person had to examine the raw data to identify telltale characteristics indicating the likely points where the sensor 102 entered and left the cold chain, and correlate those points with any other information known about the shipment, such as how long such shipments normally took, the approximate times that the shipments began and ended, etc., so as to permit the person to make an educated guess as to where to place the lines 302, 304.
After the data from a sensor 102 had been conditioned, summary data for the entire shipment could be extracted from it into a spreadsheet format. Such summary data generally included parameters such as shipment ID, origin, destination, carrier, product type, average temperature, minimum temperature, maximum temperature, time above the ideal temperature, time below the ideal temperature, trip time, and degree minutes (i.e., the total number of minutes at each degree). After extraction, the summary data could be accessed and processed by a human being using special software programs to manually generate informative graphs and charts.
After these graphs and charts were generated, the human being had to manually transfer them to a server 126 and thereby make them accessible to a customer's computer 128 (FIG. 1) via the Internet 122 for review and analysis. That is, after logging onto a website maintained on the server 126, a customer at the computer 128 could click on one of a predefined set of hyperlinks to access a corresponding, pre-generated chart or graph stored on the server 126. In some instances, after accessing such an initial chart or graph, the customer could “drill down” to additional pre-defined charts or graphs stored on the server 126 by clicking on a particular part of the initial chart or graph.
Descriptions of three types of charts and graphs that were generated in this prior art system (a box plot, a control chart, and a histogram) are provided below in connection with FIGS. 4–6. Turning first to FIG. 4, an example is shown of how a box plot 400 for accumulated data was generated. Such a box plot provided a summary of the location, spread, and skewness of a distribution. In the box plot 400, the upper quartile (Q3 or 75th percentile) and the lower quartile (Q1 or 25th percentile) of the data are portrayed by the top 410 and bottom 412, respectively, of a rectangular box 408. Roughly 50% of the data is contained within the box 408. The median (50th percentile) is portrayed by a horizontal line segment 402 within the box 408.
The lines 404 that extend from the ends 410, 412 of the box 408, called the “whiskers,” are based on the data in the tails of the data and help show the spread of the distribution. The whiskers 404 extend to the most extreme point within a calculated range (e.g., one and one-half times the distance between the ends 410, 412) beyond each end 410, 412 of the box 408. Points falling beyond the whiskers are indicated by individual stars 406. These points are potential outliers, since they are significantly different from the rest of the observations.
If the median line 402 cut the box 408 in half and the whiskers 404 on either end 410, 412 extended about the same distance from the box 408, then the distribution was symmetrical. Lack of symmetry would indicate that the data may not have come from a normal distribution. If the data was normally distributed, then roughly 99% of the data would have been contained between the whiskers 404 of the box plot 400.
FIG. 5 shows an example of a control chart 500 generated using the prior art system discussed above. Such control charts helped the user understand what their current supply chain processes were capable of and how much variation (about the mean) to expect from the current process. Such charts also allowed the user to determine whether variations from point to point were due to expected random variation or due to an assignable cause. Basically, a control chart is a run chart that includes statistically generated upper and lower control limits. The purpose of a control chart was to detect any unwanted changes in the process being analyzed. Abnormal points or certain patterns in the graph signal would reveal these changes.
Extensive research by statisticians has shown that by establishing upper and lower limits at three times the standard deviation of the process (plus and minus, respectively), 99.73% of the random variation would fall within these limits. When a point falls outside the control limits or when certain patterns occur in the data, it is usually due to an assignable cause. A process is therefore said to be in “statistical control” when the process measurements vary randomly within the control limits; that is, the variation present in the process is consistent and predictable over time. The upper and lower control limits are not the same as tolerance or specification limits. Control limits are a function of the way a process actually performs over time. Specification, or tolerance, limits, on the other hand, are a function of what people want the process to do, and may not have any direct relationship to the actual capabilities of the process.
Control charts such as that shown in FIG. 5 have three basic components: (1) performance data 502 plotted over time, (2) a centerline (CL) 504, which is the mathematical average of all the samples plotted, and (3) upper 506 and lower 508 statistical control limits (UCL & LCL) that define the constraints of common cause variations.
In the prior art system 100 discussed above, the control limits 506, 508 were used in conjunction with control charts 500 to help interpret temperature-related data accumulated by sensors 102. Control limits 506, 508 reflected the expected variation in the temperature of the cold chain being monitored. Results that fell outside of these limits were considered to be “out of control” points and would have suggested that some abnormal cause had acted on the cold chain. If the temperature data fluctuated within the limits 506, 508, it was assumed to be the result of common causes within the process (flaws inherent in the process), and could only have been affected if the system was improved or changed. If the temperature data fell outside of the limits 506, 508, it was assumed to be the result of special causes.
In the prior art system 100, several tests were used to spot variations due to assignable causes on a control chart 500: (1) one data point falling outside the control limits, (2) six or more points in a row steadily increasing or decreasing, (3) eight or more points in a row on one side of the centerline, and (4) fourteen or more points alternating up and down. These tests were conducted manually by a human being. That is, a human being had to visually inspect the control charts for the presence of one or more of the above patterns.
FIG. 6 shows an example of a histogram 600 generated using the prior art system discussed above. A histogram, such as the histogram 600, is a graphical representation of a set of measurements. It consists of columns drawn over class intervals, the heights of which are proportional to the number of measurements falling within a given interval.
A histogram is constructed from a frequency table. A frequency table is constructed by dividing the data collected into intervals or “bins,” and then counting the number of data points falling within each interval. A graph consisting of several columns is then constructed, with the height of each column being determined by the number of data points collected in a corresponding interval. In the histogram 600, the height of each column indicates the number of shipments during which the measured minimum temperature fell within a respective five degree range of temperatures.
The following example is illustrative of how the above-described charts and graphs stored on the server 126 were accessed by a customer using the prior art system 100. First, after logging onto a website maintained by the server 126, the customer could select a hyperlink corresponding to a particular characteristic (e.g., mean temperature) from among a group of such hyperlinks (e.g., mean temperature, minimum temperature, maximum temperature, degree-minutes>0° F., time>0° F., and trip time). In response to that selection, a pre-selected and pre-generated group of box plots 400 stored on the server 126 could be displayed that were segregated according to some pre-defined criterion (e.g., by the distribution centers through which monitored product flowed). The user could then click on one of the box plots 400 to access a pre-generated control chart 500 stored on the server 126 that included a set of data points upon which the selected box plot was based. The user could then click on one of the data points 502 in the control chart 500 to retrieve from the server 126 either a graph of data from, or a summary chart of information relating to, the trip with which the selected data point 502 corresponded. In some prior art systems the customer could also retrieve from the server 126 a pre-generated histogram 600 for the originally selected criterion, e.g., mean temperature.
In such systems, all of the charts and graphs available for display to the customer were generated and stored on the server 126 sometime before the customer logged onto the website. Once uploaded to the server 126, the content of, and available formats for, those charts and graphs was essentially fixed unless and until new or different charts and graphs were separately generated and uploaded to the server 126. Thus, while the customer was able to select from among a number of pre-selected and pre-generated charts and graphs that had been uploaded to the server 126, the customer's control of (1) which charts and graphs were generated and therefore available for review, (2) the content of the available charts and graphs, and (3) the format in which the available charts or graphs were presented, was limited to requesting that additional or different charts or graphs be manually created and made available via additional hyperlinks on the website.
Returning again to FIG. 1, for purposes entirely unrelated to the monitoring of temperature, in advance of sending a shipment of product 104, a computer 118 at the shipping location 106 typically sent an advanced shipping notification (ASN), sometimes alternatively referred to as “dispatch advice,” an “advance ship notice,” a “bill of lading,” a “ship notice/manifest,” etc., over the Internet 122 to a computer 120 at the receiving location 108. As used herein, “advanced shipping notification” is intended to broadly encompass all such notice types. An example of an extensible markup language (XML) file structure for an ASN is attached as Appendix A, to provisional application Ser. No. 60/500,565, incorporated by reference above. Another example of an ASN file structure is set forth in electronic data interchange (EDI) transaction set 856. In addition to other pieces of information, the ASN generally included a tracking number for the shipment. With the tracking number, either of the computers 118 or 120 could access a server 124 maintained by the carrier to track the product 104 through the cold chain. Operators of the computers 118 and 120 could therefore retrieve from the server 124 information such as when the product 104 left the shipping location 106 and arrived at the receiving location 108, as well as occasions on which the product 104 reached certain transition points along the way that were recorded by the carrier.